Constrain distance function using is_iterator type trait#96
Constrain distance function using is_iterator type trait#96jeremy-murphy wants to merge 16 commits into
Conversation
|
Looks like this works in principle, now to add a unit test. (haha, so much for TDD...) |
|
One potential issue is that |
|
We should use |
|
The same restriction should probably be applied to |
Yeah, that's what I figured -- if it unconditionally uses |
OK, sure thing. |
|
@jeremy-murphy, hey, I started working on the unit test for #96. |
Signed-off-by: Amlal El Mahrouss <amlal@nekernel.org>
Added a test for custom distance function using Foo struct.
|
Yeah, so I don't get why the unit test fails with: when |
|
I'll do |
|
If you're referring to the test then it is needed for |
Added overload for advance function to handle integers.
| { | ||
| using boost::advance; | ||
| Foo bar; | ||
| advance(bar, 3); | ||
| BOOST_TEST(bar.x == 30); | ||
| } |
There was a problem hiding this comment.
This test is not quite as convincing as the one for distance, because it still passes if I take away the constraint on advance. Any advice on how to make it fail without the change to advance?
There was a problem hiding this comment.
I guess this question is directed at you, @Lastique.
There was a problem hiding this comment.
Regardless of the constraint on boost::advance, the friend advance is the more preferable overload as it is not a template and the arguments don't require conversions. Make it a less preferable overload so that boost::advance is picked in overload resolution, e.g. make the second argument long or something.
distancewill match anything, which gets annoying when your geometry algorithm for distance is...distance.